home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0398.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  3.5 KB  |  76 lines

  1. It seems to me that there are several flavours of useful annotations:
  2.  
  3. News style "responses"     (similar to Dan Connolly's suggestion)
  4. ======================
  5.  
  6. Here people can post responses to documents. This could be restricted to
  7. a special class of discussion documents or it could be completely open
  8. mechanism allowing responses to any document.
  9.  
  10. You would read the original document and then compose a response (as an
  11. ordinary html document). The response is then notified to the server owning
  12. the original document. The notification is either a copy of the response
  13. document or a http-like reference to it.
  14.  
  15. When people next read the original document, the browser shows that a response
  16. has been posted. This is read by clicking the "view next response" button
  17. which could be part of the browser's user interface or a link in the document.
  18.  
  19. If the server had write permission it could modify the original document to
  20. include a link to the list of responses. By using a hidden link, i.e. a
  21. different tag than <A>, the browser could indicate that the document had
  22. one or more responses, without regard to where they are placed in the
  23. documents text itself.
  24.  
  25. In my opinion, a better approach is for the server to keep a directory of
  26. which documents have responses, and to add the information dynamically when
  27. sending the original document (caching could be used to avoid the directory
  28. look-up penalty for popular documents). The response info could be sent as
  29. part of the document or via additional parameters.
  30.  
  31. This mechanism works even when the server doesn't have write access, and can
  32. take advantage of broadcast protocols like news. Dan's suggestion is fine in
  33. the short term, but I think we need to think about this in more depth,
  34. without restricting ourselves to using only the current protocol
  35. infrastructure. I am particularly enamoured by ANSA's trading mechanism as a
  36. means of managing the caching of documents and responses, but haven't the time
  37. to elaborate on this right now.
  38.  
  39. One thing we should consider ASAP is to include details of document creation
  40. or last  modification date/time. This is essential for purging/refreshing
  41. cache information. I also think it would be a good idea to include the
  42. requestors identity in the request formats sent to servers, going beyond the
  43. internet address info. This would be really helpful for supporting
  44. closed-readership groups.
  45.  
  46. Direct Annotations (Post Its)
  47. =============================
  48.  
  49. These are notes which appear in place when you read the original document,
  50. although in some cases you might need to click on a postIt button to see the
  51. actual note which then appears as a pop-up (pale yellow?) window. These may
  52. be penned handwritten comments, or short voice annotations. I can easily
  53. imagine people wanting to using conventional proof-reading marks.
  54.  
  55. The annotations are attached to anchors within documents - either
  56. pre-existing anchors or via pattern matching. In either approach problems may
  57. occur when the original document is modified. A heuristic pattern maching
  58. approach would be reasonably insensitive to insertions and small changes in
  59. the region of attachment - you don't need an absolute match!
  60.  
  61. This flavour of annotations can be managed in a simlar way to the previous
  62. style. 
  63.  
  64. General Revision Histories
  65. ==========================
  66.  
  67. A third flavour of annotions, is to keep a revision history of changes to
  68. documents. A check-out/check-in mechanism can be used to avoid the need for a
  69. branching structure caused by people independently modifying the same version.
  70.  
  71.  
  72. Dave Raggett,
  73.  
  74. HP Labs, Bristol, UK   (dsr@hplb.hpl.hp.com) +44 272 228046
  75.  
  76.